In recent years, techniques referred to as a VXLAN (Virtual Extensible Local Area Network), NVGRE (Network Virtualization using Generic Routing Encapsulation), and STT (Stateless Transport Tunneling) have been proposed as tunneling protocols that could be applied to cloud computing. NPL 1 is a draft of the VXLAN.
In the VXLAN, a layer 2 frame is encapsulated at a tunnel endpoint that functions as an endpoint of a virtual tunnel. In this encapsulation, a VXLAN Network Identifier (VNI) having a length of 24 bits is added to an encapsulation header (outer header) (see “5. VXLAN Frame Format” on Page 9 and the subsequent description thereof in NPL 1). The length of the VNI is twice the length of a VLAN ID defined by IEEE802.1Q. Thus, since the number of “tenants (users sharing a physical network)” in the above cloud computing environment can significantly be increased (up to about 16.77 million (2^24)), the VXLAN has been drawing attention. In addition, NPL 2 is a draft of the NVGRE in which the same tunneling as that of the VXLAN is performed. In the NVGRE, the number of segments obtained through logical division can also be increased by using a Tenant Network Identifier (TNI) having a length of 24 bits.
In addition, a technique referred to as OpenFlow has been proposed (see NPLs 3 and 4). OpenFlow recognizes communications as end-to-end flows and performs path control, failure recovery, load balancing, and optimization on a per-flow basis. Each OpenFlow switch according to NPL 4 has a secure channel for communication with an OpenFlow controller and operates according to a flow table suitably added or rewritten by the OpenFlow controller. In the flow table, a set of the following three is defined for each flow: Match conditions (Match Fields) against which a packet header is matched; Flow statistical information (Counters); and Instructions that define at least one processing content (see section “4.1 Flow Table” in NPL 4).
For example, when an OpenFlow switch receives a packet, the OpenFlow switch searches the flow table for an entry having a match condition that matches header information of the received packet (see 4.3 “Match Fields” in NPL 4). If, as a result of the search, the OpenFlow switch finds an entry that matches the received packet, the OpenFlow switch updates the flow statistical information (Counters) and processes the received packet on the basis of a processing content(s) (packet transmission from a specified port, flooding, dropping, etc.) written in the Instructions field of the entry. If, as a result of the search, the OpenFlow switch does not find an entry that matches the received packet, the OpenFlow switch transmits an entry setting request to the OpenFlow controller via the secure channel. Namely, the OpenFlow switch requests the OpenFlow controller to transmit control information for processing the received packet (Packet-In message). The OpenFlow switch receives a flow entry in which at least one processing content is defined from the OpenFlow controller and updates the flow table. In this way, by using an entry stored in the flow table as a processing rule, the OpenFlow switch performs packet forwarding.